Skip to content

This is a *proposed* change to address the issue that the launch requ… #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

rkeithhill
Copy link
Contributor

…est could come after the configurationDone request (microsoft/vscode#3548).

This commit "should" allow the messages to come in either order and still work. *However, it needs a good review. * BTW it appears all the messages are processed on the same thread (or maybe that was coincidence). If that is the case then perhaps the lock is not needed. Still it is a fairly lightweight lock - one bool check and an assignment.

…est could come after the configurationDone request (microsoft/vscode#3548).

This commit "should" allow the messages to come in either order and still work.  However, it needs a good review.  BTW it appears all the messages are processed on the same thread (or maybe that was coincidence).  If that is the case then perhaps the lock is not needed.  Still it is a fairly lightweight lock - one bool check and an assignment.
{
// Ensure that only the second message between launch and
// configurationDone requests, actually launches the script.
lock (syncLock)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically you shouldn't need a lock for this since all requests are handled serially by the MessageReader (a SynchronizationContext handles reads in a queue). Did you run into a case where there was a race condition or are you just being cautious?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Was just being overly cautious. I'll drop the locks.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem! There can be some more subtle behavior with async methods that could require locking but we can discuss that another time ;)

@rkeithhill
Copy link
Contributor Author

@daviwil Are you OK with this PR after commit f1be4b6?

@daviwil
Copy link
Contributor

daviwil commented Mar 3, 2016

Yeah, sorry I didn't follow up on that! I'll merge it.

daviwil added a commit that referenced this pull request Mar 3, 2016
…ling

This is a *proposed* change to address the issue that the launch requ…
@daviwil daviwil merged commit 3bd9a26 into PowerShell:master Mar 3, 2016
@rkeithhill rkeithhill deleted the rkeithhill/robust-launch-handling branch March 3, 2016 23:55
@rkeithhill
Copy link
Contributor Author

No problemo. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants